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FOREWORD 


Among  the  responsibilities  assigned  to  the  Office  of  the  Manager,  National 
Communications  System,  is  the  management  of  the  Federal  Telecommunication 
Standards  Program  which  is  an  element  of  the  overall  GSA  Federal  Standardization 
Program.  Under  this  program,  the  NCS,  with  the  assistance  of  the  Federal 
Telecommunication  Standards  Committee,  identifies,  develops,  and  coordinates 
proposed  Federal  Standards  which  either  contribute  to  the  interoperability  of 
functionally  similar  Federal  telecommunication  systems  or  to  the  achievement  of  a 
compatible  and  efficient  interface  between  computer  and  telecommunication 
systems.  In  developing  and  coordinating  these  standards  a considerable  amount  of 
effort  is  expended  in  initiating  and  pursuing  joint  standards  development  efforts 
with  appropriate  technical  committees  of  the  Electrtmic  Industries  Association,  the 
American  National  Standards  Institute,  the  International  Organization  for 
Standardization,  and  the  International  Telegraph  and  Telephone  Consultative 
Committee  of  the  International  Telecommunication  Union.  This  Technical 
Information  Bulletin  presents  an  overview  of  an  effort  which  is  contributing  to  the 
development  of  compatible  Federal,  national,  and  international  standards  in  the 
area  of  data  communication  interface  standards.  It  has  been  prepared  to  inform 
interested  Federal  activities  of  the  progress  of  these  efforts.  Any  comments, 
inputs,  or  statements  of  requirements  which  could  assist  in  the  advancement  of  this 
work  are  welcome  and  should  be  addressed  to: 

Office  of  the  Manager 
National  Communications  System 
ATTN:  NCS-TS 
Washington,  D.C.  20305 
(202)  692-2124 
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BACKGROUND 


Intense  activity  over  the  past  several  years  is  leading 
to  a new  generation  of  interface  standards  for  the  newly 
emerging  public  data  networks  being  implemented  in  numerous 
countries  around  the  world.  These  new  data  networks  will 
offer  a variety  of  service  tailored  to  support  the  rapidly 
expanding  computer  and  digital  communications  requirements. 

A summary  of  the  public  data  network  standards  work  is 
‘ presented  in  NCS  TIB  79-2. 

The  principle  technology  used  for  these  new  networks  is 
‘ packet-switching.  In  applying  the  packet-switching  techniques 

the  International  Telegraph  and  Telephone  Consultative 
Committee  (CCITT)  approved  at  their  Sixth  Plenary  Assembly, 
September  - October  1976,  Recommendation  X.25,  Interface 
between  Data  Terminal  Equipment  (DTE)  and  Data  Circuit- 
terminating Equipment  (DCE)  for  Terminals  Operating  in  the 
Packet  Mode  on  Public  Data  Networks.  X.25  defines  operation 
for  virtual  calls  and  permanent  virtual  circuits  which 
effectively  simulate  dial-up  end-to-end  connections  and 
dedicated  end-to-end  connections,  respectively,  using  packet- 
switching techniques.  For  the  details  of  the  latest  Working 
draft  of  X.25  for  virtual  circuit  service,  refer  to  NCS 
TIB  79-3.  AP  ^ 

The  virtual  circuit  mode  of  operation  has  proved  effective 
for  some  applications  but  is  not  fully  efficient  for  a large 
spectrum  of  requirements.  As  a result,  efforts  through 
the  American  National  Standards  Institute  (ANSI)  to  CCITT 
and  the  International  Organization  for  Standardization  (ISO) 
by  the  USA  have  resulted  in  gaining  acceptance  for  expansion 
of  X.25  to  include  a datagram  mode  of  operation.  Datagrams 
will  provide  a fast,  transport  of  small,  independent  units 
of  data.  Appendix  1 of  this  TIB  presents  a USA  contribution 
to  ISO  which  describes  the  features  and  requirements  of 
datagram  operation  as  a complement  to  virtual  call  operation. 

As  a result  of  a meeting  of  the  CCITT  Special  Rapporteur 
on  Datagram  Service,  Mr.  H.  Bertine  of  Bell  Labs,  USA,  good 
acceptance  of  the  Datagram  concept  was  finally  received 
from  a number  of  participating  countries.  It  was  agreed 
that  the  test  describing  Datagram  operation  should  be  integrated 
into  the  level  3 part  of  the  X.25  virtual  call  specification. 

: j Appendix  2 to  this  TIB  presents  a copy  of  this  revised  text. 

■ I Where  the  proposed  draft  refers  to  paragraphs  as  being 

( ^ "unchanged"  without  indicating  the  text,  reference  should 

' 1 be  made  to  the  text  in  the  Appendix  of  NCS  TIB  79-3. 
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Further  work  will  be  done  to  complete  the  datagram  work 
during  further  meetings  in  April  and  Autumn  1979.  It  is 
expected  that  a final  X.25  covering  both  virtual  circuit 
service  and  Datagram  service  will  be  approved  by  CCITT  in 
1980.  At  that  time  it  is  proposed  that  X.25  will  be  adopted 
as  a Federal  Standard.  Any  comments  or  input  from  Federal 
activities  in  the  meantime  will  be  welcome  to  help  achieve 
a solution  that  will  meet  the  Federal  needs. 


NCS  TIB  79-4 


APPENDIX  1 

UNITED  STATES  OF  AMERICA 
TECHNICAL  CONTRIBUTION  TO  THE 
INTERNATIONAL  ORGANIZATION  FOR  STANDARDIZATION 

REQUIREMENT  FOR  DATAGFAM  SERVICE 


X3S37-77-85 


ISO/TC  97 /SC  6 
DATE:  October  1977 


ISO 

INTERNATIONAL  ORGANIZATION  FOR  STANDARDIZATION- 
ORGANISATION  INTERNATIONAL  de  NORMALISATION 
ISO/TC  97 /SC  6 
DATA  COMMUNICATIONS 


PROJECT:  15 

SOURCE:  United  States  of  America 

TITLE:  Requirement  for  Datagram  Service 

1.  Introduction 

This  document  sets  forth  the  USA  requirement  for  datagram  service  to 
be  supported  by  public  data  networks.  It  is  specifically  assumed  that 
a public  data  network  will  offer  virtual  call  service  via  the  X.25 
protocol  recommendation.  It  is  proposed  that  the  X.25  specification 
be  augmented  to  incorporate  a datagram  mode  of  operation  at  level  3 
(packet  level). 

2.  Historical  Background 

Packet  communication  networks  are  either  in  operation  or  under  construction 
in  at  least  20  countries,  and,  in  some  countries,  more  than  one  network 
is  to  be  found.  Commercial  interest  in  these  networks  is  increasing 
and  both  public  and  private  networks  have  been  developed.  A natural 
consequence  of  the  development  of  t>ese  networks  is  the  need  and  desire 
to  establish  standards  for  interfacing  to  them.  Such  standards  would 
permit  computer  equipment  manufacturers  to  build  and  support  compatible 
software  and  hardware  and  could  also,  potentially,  ease  the  ultimate 
task  of  interconnecting  many  of  these  networks  to  each  other. 

The  USA  recognizes  that  CCITT  Recommendation  X.25,  in  %diich  the  virtual 
call  packet  interface  is  defined,  represents  an  important  step  in  the 
development  of  standard  service  and  interface  specifications.  However, 
for  the  reasons  set  forth  below,  the  USA  takes  the  position  that  an 
additional  service,  notably  a datagram  mode  of  operation,  is  needed 
to  support  public,  private,  and  government  requirements  for  efficient 
and  reliable  data  communication.  An  interface  Standard  for  such  a 
service  would  be  equally  beneficial  to  all  three  sectors. 


3.  Datagram  Service  Definition 


A detailed  definition  of  a datagram  interface  ^e.g.,  showing  how  it 
could  be  integrated  into  the  level  3 part  of  CCITT  Recommendation  X.25) 
is  beyond  the  scope  of  this  paper,  but  a companion  contribution  offering 
a precise  description  of  datagram  procedures  and  formats  is  in  preparation 
by  the  USA. 

Datagram  service  can  be  thought  of  as  a natural  dual  of  virtual  circuit 
service  (as  characterized  in  Recommendation  X.25).  Virtual  circuit 
service  is  organized  around  the  notion  of  providing  service  over  a 
period  of  time  during  which  one  or  more  packets  of  information  might 
be  exchanged  in  a sequential  fashion  between  DTE's.  Datagram  service 
is  organized  around  messages  which  are  complete  in  themselves  and  are 
unrelated  (at  least  in  the  view  of  the  transporting  network)  to  any 
other  messsages  in  transit  between  or  among  DTE's. 

Thus,  the  unit  of  operation,  accounting,  and  control  in  the  two  services 
is  different.  Control  in  virtual  circuit  service  is  exercised  per  virtual 
circuit  while  in  datagram  service,  it  is  exercised  per  datagram.  It 
follows  that  this  distinction  leads  to  a differing,  but  complementary 
array  of  services,  the  requirement  for  which  is  discussed  in  the  next 
section. 

A working  definition  of  datagram  service  can  be  offered  in  a few  lines: 

1.  A datagram  is  self-contained,  carrying  sufficient  information 

to  be  routed  from  source  DTE  to  destination  DTE  without  reliance 
on  earlier  exchanges  between  source  or  destination  DTE 
and  the  transporting  network. 

2.  A datagram  is  delivered  in  such  a way  that  the  receiver  can 
determine  the  boundaries  (i.e.,  beginning  and  end)  of  the  datagram 
as  it  was  entered  by  the  source  DTE.  The  simplest  way  to  achieve 
this  is  to  deliver  the  datagram  intact  as  one  unit  to  its  destina- 
tion, but  other  methods  are  not  ruled  out. 

3.  A datagram  is  delivered  with  Viigh  probability  to  the  desired 
destination,  but  it  may  possibly  be  lost. 

4.  The  sequence  in  which  datagrams  are  entered  into  a network  by 
a source  DTE  is  not  necessarily  preserved  upon  delivery  at  a 
destination  DTE. 

5.  If  a datagram  cannot  be  delivered  to  the  destination  or  is 
detectably  lost,  the  network  will  attempt  to  advise  the  source 
DTE  through  provision  of  a "non-delivery  notice"  which  indicates, 
to  the  best  of  the  network's  knowledge,  why  the  datagram  could 
not  be  delivered.  To  distinguish  among  datagrams  for  the  purpose 
of  providing  error  indications,  the  network  will  employ  a datagram 
identifier  supplied  by  the  source  DTE  in  each  datagram.  Uniqueness 
of  this  identifier,  if  desired,  is  the  responsibility  of  the 
source  DTE  and  is  not  necessarily  guaranteed. 


There  are  many  other  details  such  as  formats  and  DTE/DCE  state  diagrams 
which  are  set  forth  in  the  previously  mentioned  companion  contribution 
on  datagram  interface  specfication. 

The  quality  of  virtual  circuits  and  datagrams  can  be  easily  seen  by 
a few  simple  comparisons.  Referring  to  the  five  definitional  statements 
above,  we  can  construct  a parallel  set  of  definitions  for  virtual  circuits: 

1.  Any  one  virtual  circuit  is  independent  of  all  others. 

2.  The  source  and  destination  DTE's  can  distinguish  the  beginning 
and  ending  of  a virtual  circuit  in  time. 

3.  A virtual  circuit  remains  "connected"  with  high  probability 

for  its  required  lifetime,  but  may  possibly  be  "reset"  prematurely. 

4.  Virtual  circuits  are  not  necessarily  set-up  in  any  particular 
order. 

5.  If  a virtual  circuit  "breaks"  the  network  attempts  to  advise 

the  parties  involved.  Virtual  circuits  are  identified  by  numbers 
which  may  be  assigned  by  DTE  or  DCE,  depending  upon  the  circumstances 
of  the  virtual  circuit  set-up. 

While  the  parallel  is  not  exact,  it  is  close  enough  to  show  clearly 
that  virtual  circuits  are  entities  which  have  duration  in  time  while 
datagrams  have  duration  in  the  data  space.  The  two  notions  lead  to 
qualitatively  different  but  complementary  services. 

4.  Datagram  Service  Applications 

4.1  Transaction  Processing 

The  processing  of  short,  self-contained  transactions  is  typical 
of  a variety  of  applications,  notably  point-of-sale  systems;  some 
classes  of  electronic  funds  transfer;  query-response  services  such 
as  credit  checking,  meter  reading,  reservation  systems,  directory 
look-up,  stolen  vehicle  identification;  5 iventory  control;  some 
aspects  of  process  control;  and  a wide  variety  of  communication 
and  control  functions  such  as  tracking,  position  locations,  distributed 
sensor  systems  and  status  reporting  systems. 

A datagram  service  matches  these  transaction  processing  requirements 
without  the  need  for  virtual  circuit  set-up  and  clearing.  Depending 
on  the  application,  the  use  of  permanent  virtual  circuits  may  be 
prohibitively  expensive  (e.g.,  more  permanent  virtual  circuits  would 
be  required  than  can  be  economically  supported  by  the  net  or  the 
subscriber)  or  the  interface  procedures  for  virtual  call  service 
(e.g.,  setting  up  and  clearing  down  a virtual  circuit  for  each  trans- 
action) may  be  intolerably  high  in  overhead. 


- ^ 


4.2  Real-time  Applications 

Because  the  datagram  service  would  treat  esch  datagram  independently, 
subscribers  would  be  free  to  construct  protocols  at  level  4 which 
employ  a variety  of  criteria  for  packet  ordering  and  processing 
without  the  delay  overhead  of  explicit  sequencing  by  the  public 
data  network.  Ihis  is  particularly  attractive  in  applications  where 
it  is  not  necessary  for  every  packet  to  be  delivered,  but  low  delay 
for  those  packets  which  are  delivered  is  important  (real-time  data 
sampling,  tracking,  process  control  and  so  on).  Provision  of  virtual 
circuit  service  (reliable,  sequenced  delivery)  can  introduce  undesirable 
delays  for  packet  delivery  which  may  render  the  data  useless  when 
it  is  finally  delivered.  This  is  particularly  the  case  for  real- 
time cpolications  in  which  the  data  has  very  high  time  value  which 
drops  rapidly  to  zero  (or  is  negative  - i.e.,  a liability  if  old 
data  interferes  with  delivery  of  fresh  data!)  in  a short  time. 

Many  of  these  applications  are  more  concerned  about  the  age  of  incoming 
data  than  their  order. 

4.3  Network  Flexibility 

Datagram  traffic  can  be  freely  routed,  without  regard  to  sequencing, 
across  any  available  link  to  multi-homed  hosts,  through  any  series 
of  internetwork  gateways  without  the  need  to  maintain  state  information 
relating  datagram  packets  to  each  other  at  source  or  destination 
DCE's  or  at  intermediate  gateways.  For  those  classes  of  subscriber 
applications  not  requiring  network  sequencing,  networks  would  have 
a wider  range  of  routing  options  and  could  enhance  their  transparency 
to  intermediate  failures  (broken  lines,  DCE's,  gateways  and  the 
like). 

Interconnection  of  public  data  nets  with  private,  local  nets  such 
as  the  Xerox  Ethernet  would  be  considerably  simplified  through  the 
use  of  a public  network  datagram  mode  of  operation.  Since  such 
private  packet  nets  do  not  internally  sequence  packets,  there  would 
be  no  need  for  the  gateways  between  these  private  nets  and  public 
nets  to  set  up  and  clear  virtual  circuits  if  a public  datagram  mode 
were  available.  Indeed,  it  is  not  always  clear,  at  such  a gateway, 
when  to  set  up  or  clear  a virtual  circuit.  Use  of  datagram  mode 
in  this  case  would  eliminate  inefficiencies  for  both  the  public 
data  net  and  private  network  subscribers. 

5.  Recommendation 

In  order  to  provide  interface  procedures  for  datagram  service  (specified 
in  X.2  as  an  A facility  for  user  classes  8-11),  the  USA  recommends  that 
a datagram  mode  of  operation  be  incorporated  at  level  3 (packet  level) 
of  Recommendation  X.25. 
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COM  VII  Wo.  295-E 


International  Telegraph  and  Telephone 
Consultative  Coaaittee 
(C.C.I.T.T.) 

Period  1977  - 1980 

Question:  14/VII 


Original;  English 


Date;  January  1979 


STODY  CaOOF  VII  - CONTRIBUTION  NO.  295 


lODRCE:  Special  Rapporteur  on  Dategran  Service  - H.  Bertine 

TITLE:  X.2S  Level  3 Revision  to  Include  Datagran  Interface  Procedures 

IimOPUCTlON 


At  the  30  Hoveaber  - 1 Decenber  1978  Special  Rapporteur's  aeeting  on  datagraa 
service,  it  was  agreed  that  the  datagram  interface  procedures  should  be  integrated 
into  the  text  for  X.2S,  level  3.  Mr.  Polts,  USA,  agreed  to  do  the  necessary 
editing.  The  resulting  working  draft  is  provided  in  the  annex  to  this  document 
and  is  based  on  the  text  of  COM  VII  No.  217  as  modified  by  the  Special  Rapporteur' 
meeting  on  X.2S  level  3,  27-29  November  1978.  The  unchanged  sections  are  noted 
accordingly,  and  marginal  lines  appear  where  changes  have  been  made. 
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3.  DESCRIPTIOH  OF  THE  PACKET  LEVEL  DTE/DCE  IHTERFACE  FOR  VIRTUAL  CALL.  PEmAWEMT 
VPTUAL  CaCUIT  Jim  DATACRAW  FACILITIES  (LEVEL  “ 


Ihii  aection  of  the  Recoenendation  relatea  to  the  transfer  of  packets  at  the  DTE/DCE 
interface.  The  procedures  apply  to  packets  which  are  successfully  transferred 
across  the  DTE/DCE  interface. 

Each  packet  to  be  transferred  across  the  DTE/DCE  interface  shall  be  contained 
within  the  link  level  inforwation  field  which  will  delimit  its  length,  and  only 
one  packet  shall  be  contained  in  the  information  field. 

HDTE:  Possible  insertion  of  more  than  one  packet  in  the  link  level  information 
field  is  for  further  study. 

To  enable  simultaneous  virtual  calls,  permanent  virtual  circuits  and/or  datagrams, 
logical  channels  are  used.  Each  virtual  call,  permanent  virtual  circuit,  and  | 

datagram  channel  is  assigned  a logical  channel  group  number  (less  than  or  equal 
to  IS)  and  a logical  channel  number  (less  than  or  equal  to  255).  For  virtual 
calls  a logical  channel  group  number  and  a logical  channel  niaber  are  assigned 
during  the  call  set-up  phase.  For  permanent  virtual  circuits  and  datagram  channels,  | 
log.'-al  chanrjl  group  numbers  and  logical  channel  numbers  are  assigned  in  agreement 
nith  the  Administration  at  the  time  of  subscription  to  the  service.  The  range 
of  logical  channels  used  for  virtual  calls  is  agreed  with  the  Administration  at 
the  time  of  aubscription  to  the  service. 

Annex  1 shows  the  state  diagrams  which  give  a definition  of  events  at  the  packet 
level  DTE/DCE  interface  for  each  logical  channel.  Figures  15/X.25,  16/X.25  and 
17/X.25  apply  to  logical  channels  used  for  virtual  calls;  Figures  i5/X.25  and 
17/X.25  apply  to  logical  channels  used  for  permanent  virtual  circuits  and  datagrams. 

Annex  2 gives  details  of  the  action  taken  by  the  DCE  on  receipt  of  packets  in 
each  state  aho%m  in  Annex  1.  Details  of  the  actions  which  should  be  taken  by 
the  DTE  are  for  further  study.  Tables  10/X.25-13/X.2S  apply  for  virtual  calls 
and  Tables  11/X.25-13/X.25  apply  for  permanent  virtual  circuits  and  datagrams. 

Packet  formats  are  given  in  Section  4 of  this  Recomsendation. 

3.1  Procedures  for  Virtual  Calls  (Delete  the  three  paragraphs  under  Section 
3.1;  Subsections  3.1.1  through  3.1.12  are  unchanged.) 

3.2  Procedure  for  Permanent  Virtual  Circuits  and  Dataxrams 

For  permanent  virtual  circuits  and  datagrams  there  is  no  call  set-up  or  clearing. 

A datagram  packet  includes  the  destination  DTE  address.  The  source  address  may 
also  be  used. 

NOTE:  A DTE  address  suy  be  a DTE  network  addreas,  an  abbreviated  address  or  any 
other  DTE  identification  agreed  for  a period  of  time  between  the  DTE  and  the  DCE. 

3.3  Procedures  for  Data  and  Interrupt  Transfer 

The  data  transfer  procedure  described  in  the  following  section  applies  independently 
to  each  logical  channel  exiating  at  the  DTE/DCE  interface. 

Normal  network  operation  dictates  that  user  data  in  data,  interrupt  and  datagram 
packets  are  all  passed  transparently,  unaltered  through  the  network  in  the  case 
of  packet  DTE  to  packet  DTE  communications.  Order  of  bits  of  user  data  ia  preaerved. 
Packet  sequences  are  delivered  as  complete  packet  aequences  for  virtual  call  and 
permanent  virtual  circuit  operation.  DTE  Diagnostic  Codes  are  treated  at  described 
in  Sections  4.2.3,  4.4.3  and  4.5.1. 
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3.3.1  Sftet  for  D«t«  Tr«n»fer 


A virtual  call  logical  channel  it  in  the  DATA  TRANSFER  atate  after  coapletion 
of  call  eatabliahment  and  prior  to  clearing  or  a restart  procedure.  Feraanent 
virtual  circuit  and  datagraa  logical  channels  are  continually  in  the  DATA  TRANSFER 
state  except  during  the  restart  procedure.  Data,  datagram,  interrupt,  flow  control, 
datagram  service  signal,  and  reset  packets  asy  be  transmitted  and  received  by 
a DTE  in  the  DATA  TRANSFER  state  of  a logical  channel  at  the  DTE/DCE  interface. 

In  this  state,  the  flow  control  and  reset  procedures  described  in  section  3.4 
apply  to  data  transmission  on  that  logical  channel  to  and  from  the  DTE. 

For  virtual  calls,  data,  interrupt,  flow  control  and  reset  packets  transmitted 
by  a DTE  will  be  ignored  by  the  DCE  when  the  logical  channel  is  in  the  DCE  CLEAR 
INDICATION  state.  When  a virtual  call  is  cleared,  data  and  interrupt  packets 
aay  be  discsrded  by  the  network.  (See  section  3.6).  Data,  interrupt,  flow  control 
and  reset  packets  that  are  in  the  network  and  destined  for  a DTE,  the  interface 
of  which  enters  the  DTE  CLEAR  REQUEST  state  (p6)  may  be  delivered  before  the  DCE 
CLEAR  CONFIRMATION  packet  is  sent  to  thst  DTE.  Hence  it  is  left  to  the  DTE  to 
define  DTE  to  DTE  protocols  able  to  cope  with  the  various  possible  situations 
that  nay  occur. 

3.3.2  Numbering  of  Fackets 

Each  data,  or  datagram  and  datagram  service  signal  packet  transmitted  at  the  DTE/DCE 
interface  for  each  direction  of  transmission  in  a virtual  call,  permanent  virtual 
circuit,  or  datagram  channel  it  sequentially  numbered. 

The  sequence  numbering  schesie  of  the  psckets  is  performed  modulo  B.  The  packet 
sequence  numbers  cycle  through  the  entire  range  0 to  7.  As  an  additional  facility, 
some  Administrations  will  provide  a sequence  numbering  scheme  for  packets  being 
performed  modulo  128.  In  this  case,  packet  sequence  numbers  cycle  through  the 
entire  range  0 to  127.  The  modulo,  8 or  128,  is  the  same  for  both  directions 
of  transmission  and  is  common  for  all  logical  channels  at  the  DTE/DCE  interface. 

Only  data,  datagram  and  datagram  service  signal  packets  contain  this  sequence 
number  called  the  packet  send  sequence  number  P(S). 

The  first  data,  datagram,  or  datagram  service  signal  packet  to  be  transmitted 
across  the  DTE/DCE  interface  for  a given  direction  of  data  transmission,  when 
the  logical  channel  is  in  the  DATA  TRANSFER  state,  has  a packet  send  sequence 
number  equal  to  0. 

A F (S)  in  a received  data,  datagram,  or  datagram  service  signal  packet  not  containing 
the  proper  sequence  number  on  a logical  channel  is  considered  by  the  DCE  as  a 
local  procedure  error  (see  Sections  3.4.2  and  4.4.3);  the  DCE  then  resets  the 
logical  channel. 

3.3.3  User  Data  Field  Length 

The  standard  maximum  User  Data  Field  length  is  128  octets  for  virtual  calls,  permanent 
virtual  circuits  and  datagrams. 

In  addition,  and  in  conjunction  with  optional  user  facilities,  other  maximum  data 
field  lengths  may  be  offered  by  Administrations  for  virtual  call  and  permanent 
virtual  circuit  operation. 

If  an  optional  maximum  data  field  length  is  selected  at  subscription  it  becomes 
the  default  maximum  data  field  length  coason  to  all  virtual  call  and  permanent 
virtual  circuit  logical  channels  at  the  DTE/DCE  interface.  The  Administration 
may  also  permit  selection  of  a maximum  data  field  length  on  a per  call  basis  for 
virtual  calls  (see  Section  S.1.2). 
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OptioQal  Baxiaum  data  field  leagcha  offered  foi  virtual  cal la  and  peraanent  virtual 
circuits  will  be  chosen  each  Adainistration  from  the  following  list:  16,  32, 

64,  256,  512  and  1024  octets. 

Ihe  data  field  of  data  and  datagram  packets  transaitted  by  a DTE  or  DCE  aay  contain 
any  number  of  bits  up  to  the  agreed  maxi ana. 

For  virtual  call  and  permanent  virtual  circuit  operation,  if  a DTE  or  DCE  wishes 
CO  indicate  a sequence  of  aore  chan  one  packet,  it  uses  a MORE  DATA  aark  as  defined 
below: 

(Reaaiiuler  of  3.3.3  unchanged) 

3.3.4  Qualifier  Bit  (Unchanged  except  add  the  following  additional  paragraph 
at  end  of  section.) 

For  datagram  operation,  the  qualifier  bit  is  set  to  0 in  all  datagram  packets 
and  is  set  to  1 in  all  datagram  service  signal  packets. 

3.3.5  Interrupt  Procedure 

The  interrupt  procedure  applies  only  to  virtual  call  and  permanent  virtual  circuit 
operation.  It  allows  a DTE  to  transmit  data  to  Che  remote  DTE,  without  following 
the  flow  control  procedure  applying  to  data  packets  (see  section  3.4).  The  interrupt 
procedure  can  only  apply  in  the  FLOW  CONTROL  READY  state  (dl)  within  the  DATA 
TRANSFER  state  (p4). 

(Remainder  of  3.3.5  unchanged) 

3.3.6  Datagram  Identification 

Each  datagram  transmitted  at  the  DTE/DCE  interface  for  each  direction  of  transmission 
aay  be  uniquely  mimbered  with  a datagram  identification  number.  Assignment  of 
the  values  to  the  datagram  identification  is  a DTE  responsibility  and  may  be  assigned 
according  to  any  algorithm.  The  network  will  not  operate  on  the  datagram  identification 
except  to  return  the  information  in  the  appropriate  network  generated  datagram 
service  signal  packet. 

3.3.7  Datagram  Service  Signals 

The  DCE  will  be  capable  of  transferring  to  the  DTE  service  signals  as  specified 
in  RecoMendation  X.96.  The  datagram  service  signals  will  be  carried  in  datagram 
service  signal  packets  trtiich  will  include  the  datagram  identification  and  address 
information,  if  valid,  associated  with  the  origiiuil  datagram  for  which  the  service 
signal  applies.  Ihe  original  destination  address  is  provided  in  the  datagram 
service  signal  packet  as  the  source  address  while  the  original  source  address 
is  shorn  as  the  destination  address,  when  present. 

3.4  Procedures  for  Flow  Control 


This  subsection  only  applies  to  the  data  transfer  phase  and  specifies  the  procedures  I 
covering  flow  control  of  dsta,  datagrsa  end  datagrsa  service  signal  packets  and  | 

reset  on  each  logical  channel. 

For  each  direction  of  data  transmission  on  a logical  channel  a throughput  class  I 

can  be  identified  idiich  directly  corresponds  to  the  rste  at  which  packets  csn 
be  transmitted  across  the  DTE/DCE  interfsce.  The  throughput  class  indicates  the  | 

throughput  that  does  not  need  to  be  exceeded  for  that  direction  of  traffic.  Details 
on  throughput  classes  are  given  in  3.4. 1.3. 
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3.4.1  Procedure  for  Flow  Control 


At  the  DTE/DCE  interfece  of  a logical  channeli  the  tranamiceion  of  datai  datagram 

and  datagram  aervice  aignal  packets  ia  controlled  separately  for  each  direction 

and  is  based  on  authorisations  from  the  receiver.  These  three  packet  types  are  i 

referred  below  as  flow  controlled  packets.  | 

3. 4. 1.1  Window  Description 

At  the  DTE/DCE  interface  of  a logical  channel « and  for  each  direction  of  data  ^ 

transmission,  a window  ia  defined  at  the  ordered  set  of  W consecutive  packet  tend 
sequence  numbers  of  the  flow  controlled  packets  authorised  to  cross  the  interface.  I 

The  lowest  sequence  number  in  the  window  it  referred  to  as  the  lower  window  edge. 

At  the  start  of  DATA  TRANSFER,  the  window  related  to  each  direction  of  transmission 
has  a lower  window  edge  equal  to  0. 

The  packet  send  sequence  number  of  the  first  flow  controlled  packet  not  authorised  I 

to  cross  the  interface  is  the  value  of  the  lower  window  edge  plus  W (modulo  8, 
or  128  when  extended). 

In  the  absence  of  an  optional  user  facility,  the  window  site  W for  each  direction  1 

of  transmission  at  a DTE/DCE  interface  it  common  to  all  the  logical  channels  and  I 

agreed  for  a period  of  time  between  the  DTE  and  the  Administration.  The  value 
of  W does  not  exceed  7,  or  127  when  extended  (see  Section  5.1.2). 

3.4. 1.2  Plow  Control  Principles 

A number  modulo  8,  or  128  when  extended,  referred  to  as  a packet  receive  aequence 

number  P(R),  conveys  across  the  DTE/DCE  interface  information  from  the  receiver 

for  the  transmission  of  flow  controlled  packets.  When  transmitted  across  the 

DTE/DCE  interface,  a P(R)  becomes  the  lower  window  edge.  In  this  way,  additional  I 

flow  controlled  packets  may  be  authorised  by  the  receiver  to  crosa  the  DTE/DCE  I 

interface. 

When  the  sequence  number  P(S)  of  the  next  flow  controlled  packet  to  be  transmitted  I 

by  the  DTE  is  within  the  window,  the  DCE  will  accept  this  flow  controlled  packet.  ' 

Nhen  the  sequence  number  P(S)  of  the  next  flow  controlled  packet  to  be  transmitted 

by  the  DTE  is  outside  of  the  window,  the  DCE  will  consider  Che  receipt  of  this  i 

flow  controlled  packet  from  the  DTE  as  a procedure  error  and  will  reset  the  logical  I 
channel.  The  DTE  should  follow  Che  same  procedure. 

Uhen  the  sequence  number  P(S)  of  the  next  packet  to  be  transmitted  by  the  DCE  I 

is  within  the  window,  the  DCE  is  authorised  to  tranamit  this  flow  controlled  packet  I 

Co  the  DTE.  When  the  sequence  number  P(S)  of  the  next  flow  controlled  packet 
to  be  transmitted  by  the  DCE  it  outside  of  the  window,  the  DCE  shall  not  transmit  | 

a flow  controlled  packet  to  the  DTE. 

The  packet  receive  sequence  number,  P(R),  is  conveyed  in  data,  datagram,  datagram  | 

aervice  signal,  RECEIVE  READY  (RR),  and  RECEIVE  NDT  READY  (RNR)  packets. 

The  value  of  a P(R)  received  by  the  DCE  must  be  within  the  range  from  the  last 

P(R)  received  by  Che  DCE  up  Co  and  including  the  packet  aend  sequence  number  of  I 

the  naxt  flow  controlled  packet  to  be  transmitted  by  the  DCE.  Otherwise,  the  | 

DCE  will  consider  the  receipt  of  this  P(R)  as  a procedure  error  and  will  reset 

the  logical  channel.  The  DTE  should  follow  the  sasM  procedure.  I 

The  receive  sequence  number  P(R)  is  less  than  or  equal  to  the  sequence  number 
of  the  next  expected  flow  controlled  packet  and  implies  that  the  DTE  or  DCE  transmitting 
P(R)  has  accepted  at  least  all  flow  controlled  packets  numbered  up  to  and  including 
P(R)-1. 


Ihe  only  vniveraal  aignlficance  of  a P(R)  value  ia  a local  updating  of  the  window  . 

acToaa  the  packet  level  interface.  The  P(R)  value  for  virtual  cal la  and  per«anent  | 

virtual  circuita  aay  be  uaed  within  aoae  Adainiatration'a  networka  to  convey  an 
end-to-end  acknowledgement . 

The  network  maintaina  a datagram  queue  for  each  deatination  DTE.  The  maximum 

length  of  thia  queue  ia  agreed  for  a period  of  time  between  the  DTE  and  the  Adminiatra- 

tion.  When  the  queue  ia  fulli  additional  arriving  datagraam  deatined  to  thia 

DTE  are  diacarded.  Datagram  aervice  aigoal  packeta  have  priority  over  other 

datagram  packeta  and  therefore  are  inaerted  at  the  beginning  of  the  queue.  Thia 

may  lead  to  the  DCE  diacarding  the  laat  datagram  packet  of  the  queue  if  the  maximum  I 

queue  length  ia  exceeded. 

( 

By  agreement  for  a period  of  time  between  the  DTE  and  the  Adminiatration,  a apecial  ' 

datagram  logical  channel  may  be  aaaigned  for  the  tranamiaaion  of  aervice  aignala. 

In  thia  caae,  the  maximum  length  of  the  queuea  for  datagrams  and  datagram  aervice 
aignala  are  independently  agreed  between  the  DTE  and  the  Adminiatration. 

If  the  DTE  flow  controla  the  receipt  of  datagram  aervice  aignal  packeta,  the  DCE 
cannot  guarantee  to  atore  an  indefinite  number  of  aervice  aignala.  Therefore, 
there  ia  a poaaibility  of  loaa  of  aervice  aignal  packeta  at  the  DCE.  A possible 
coupling  mechanism  to  allow  the  DCE  to  regulate  the  number  of  datagrams  generated 
by  the  DTE  in  relation  to  the  capacity  of  the  DCE  to  store  the  datagram  service 
signals  should  be  studied  to  determine  whether  such  losses  at  the  DCE  should  be 
prevented. 

3. 4. 1.3  Throughput  Class 

A throughput  clast  for  one  direction  of  tranamiaaion  ia  an  indication  of  the  throughput 
that  does  not  need  to  be  exceeded  on  the  logical  channel.  Thus,  the  network  is  asked  | 

to  allocate  such  reaourcet  that  the  throughput  class  can  normally  be  reached. 

However,  due  to  the  statistical  sharing  of  tranamiaaion  and  switching  resources, 
it  is  not  guaranteed  that  the  throughput  class  can  be  reached  lOOZ  of  the  time. 

Depending  on  the  network  and  the  applicable  conditions  at  the  considered  moment, 
the  effective  throughput  may  exceed  the  throughput  class. 

The  throughput  class  may  only  be  reached  if  the  following  conditions  are  aiet: 

(a)  the  access  data  links  of  both  ends  of  a virtual  call  or  permanent  virtual 
circuit  are  engineered  for  the  throughput  class; 

(b)  the  receiving  DTE  of  a virtual  call  or  permanent  virtual  circuit  ia  j 

not  flow  controlling  the  DCE  such  that  the  throughput  class  ia  not  reachable;  I 
and 

(c)  the  transmitting  DTE  is  sending  packeta  which  have  the  maximum  data  | 

field  length. 

The  throughput  class  it  expressed  in  octets /second;  at  a DTE/DCE  interface,  a 
maxisium  data  field  length  is  specified,  and  thus  the  throughput  data  can  be  interpreted 
by  the  DTE  as  the  number  of  full  packets /second  that  the  DTE  does  not  have  a need 
to  exceed. 

WOTE  It  The  definition  of  throughput  class  in  terms  of  quality  of  service  ia 
for  further  study. 

MDTE  2t  The  need  to  link  the  datagram  flow  control  with  the  flow  control  of 

information  associated  with  virtual  calls  and  permanent  virtual  circuita 
across  the  DTE/DCE  interface  ia  for  further  study. 
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3.4. 1.4  PTE  and  DCE  B«c«ive  l«adT  (Mt)  Packets  (Dnchauged) 

3. 4. 1.5  DTE  and  DCE  Receiv  Hot  Beady  (EUR)  Pack«t> 

BME  packets  are  uaed  by  the  DTE  or  DCE  to  indicate  a teaporary  inability  to  accept 
additional  flow  controlled  packets  for  a given  logical  channel.  A DTE  or  DCE 
receiving  an  RMR  packet  shall  stop  transaitting  flow  controlled  packets  on  the 
indicated  logical  channel « but  the  window  is  updated  by  the  P(R)  value  of  the 
IHR  packet.  The  receive  not  ready  situation  indicated  by  the  transaission  of 
an  Sint  packet  is  cleared  by  the  transaission  in  the  saae  direction  of  an  RX  packet 
or  by  a reset  procedure  being  initiated. 

The  transaission  of  an  RX  after  an  RNR  at  the  packet  level  is  not  to  be  taken 
as  a deaand  for  retransaission  of  packets  which  have  already  been  transaitted 
but  still  are  in  the  window  indicated  in  the  RR. 

3.4.2  Procedure  for  Reset 


The  reset  procedure  is  used  to  re-initialise  the  logical  channel.  When  a logical 
channel  at  the  DTE/DCE  interface  hes  just  been  reset,  the  window  releted  to  each 
direction  of  transaission  has  a lower  window  edge  equal  to  0,  and  the  nuabering 
of  subsequent  flow  controlled  packets  to  cross  the  DTE/DCE  interfsce  for  that 
direction  of  transaission  shsll  start  from  0. 

For  virtual  calls  and  peraanent  virtual  circuits,  the  reset  procedure  reaoves 
in  each  direction  all  data  and  interrupt  packets  which  aay  be  in  the  network  as  ociated 
with  that  virtual  call  or  peraanent  virtual  circuit  (See  Section  3.6).  For  data- 
graa  channels,  the  reset  procedure  does  not  cause  datagranw  or  datagraa  service 
signals  to  be  purged  within  the  network. 

The  reset  procedure  can  only  apply  in  the  DATA  TRAMSFER  state  of  the  DTE/DCE  interface. 
In  any  other  state  of  the  DTE/DCE  interface,  the  reset  procedure  is  sbandoned. 

For  eza^le,  idien  a clearing  or  restarting  procedure  is  initiated,  RESET  REQUEST 
and  RESET  INDICATION  packets  can  be  left  unconfiraed. 

For  flow  control,  there  ere  three  states  dl,  d2  and  d3  within  the  DATA  TRANSFER 
state  (p4).  They  are  FLOW  CONTROL  READY  (dl),  DTE  RESET  REQUEST  (d2),  and  DCE 
RESET  INDICATION  (d3)  as  shown  in  the  state  diagraa  in  Annex  1,  Figure  17/X.2S. 

When  entering  state  p4  the  logical  channel  is  placed  in  state  dl.  Annex  2,  Table 
11/X.2S  specifies  actions  taken  by  the  DCE  on  the  receipt  of  packets  froa  the 
DTE. 

3.4. 2.1  Reset  Request  Packet  (Unchanged) 

3. 4. 2. 2 Reset  Indication  Packet 

The  DCE  shall  indicate  a reset  by  trensaitting  to  the  DTE  e RESET  INDICATION  packet 
specifying  the  logical  channel  and  the  reeaon  for  the  resetting.  This  places 
the  logical  channel  in  the  DCE  RESET  INDICATION  state  (d3).  In  this  state,  the 
DCE  will  ignore  data,  datagraa,  interrupt,  SR  and  RNR  packets.  (See  section  3.7). 

3. 4. 2. 3 Reset  Collision  (Unchanged) 

3. 4. 2. 4 Reset  Confiraation  Packets  (Unchanged) 


3.5  Procedure  for  Restart 


The  restart  procedure  is  used  to  siaulteneously  clear  all  the  virtual  calls  and 
reset  all  the  peraanent  virtual  circuits  and  datagraa  channels  at  the  DTE/DCE 
interface.  (See  section  3.6). 
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(Remainder  of  thia  aection  unchanged) 


3.5.1  Reatart  by  the  DTE 

Ihe  DTE  may  at  any  time  requeat  a reatart  by  tranaferriag  aeroaa  the  OTE/OCE  interface 
a RESTART  REQUEST  packet.  The  interface  for  each  logical  channel  la  then  in  the 
DTE  RESTART  REQUEST  atate. 

The  DCE  will  confirm  the  reatart  by  tranaferring  a DCE  RESTART  CONFIRMATION  packet 
placing  the  logical  channela  uaed  for  virtual  calla  in  the  READY  atate  (pl)|  and  i 

the  logical  channela  uaed  for  permanent  virtual  circuita  and  datagrama  in  the  I 

FLOW  OONTBOL  READY  atate  (dl). 

The  DCE  RESTART  CONFIRMATION  packet  can  only  be  interpreted  univeraally  aa  having 
local  aignif icance.  The  time  apent  in  the  DTE  RESTART  REQUEST  atate  (r2)  will 
not  aaceed  a network  dependent  limit. 

3.5.2  Reatart  by  the  DCE 

Ihe  DCE  may  indicate  a reatart  by  tranaferring  aeroaa  the  DTE/DCE  interface  a 

RESTART  INDICATION  packet.  The  interface  for  each  logical  channel  ia  then  in 

the  DCE  RESTART  INDICATION  atate  (r3).  In  thia  atate  of  the  DTE/DCE  interface, 

the  DCE  will  ignore  data,  datagram,  interrupt,  call  aet-up  and  clearing,  flow  ' 

control,  and  react  packets. 

The  DTE  will  confirm  the  restart  by  transferring  a DTE  RESTART  CONFIRMATION  packet 
placing  the  logical  channels  used  for  virtual  calls  in  the  READY  state  (pi),  and 
the  logical  channels  used  for  permanent  virtual  circuits  and  datagrama  in  the  j 

FLOW  CONTROL  READY  state  (dl).  (See  section  3.7). 

3.5.3  Restart  Collision  (Unchanged) 

3.6  Effect  of  Clear,  Reset  and  Reatart  Procedures  m the  Transfer  of  Packets  I 

(Unchanged  except  add  the  following  paragraph.) 

For  datagram  channela,  the  reset  procedure  does  not  cause  datagrams  or  datagram  | 

service  signals  to  be  purged  within  the  network.  | 

3.7  List  of  System  Parameters  (Unchanged) 

3.8  Effects  of  Levels  1 and  2 on  Level  3 

Changes  of  operational  states  of  level  1 and  2 of  the  DTE/DCE  interface  do  not 
implicitly  change  the  state  of  each  logical  channel  at  level  3.  Such  changes 
when  they  occur  are  explicitly  indicated  at  level  3 by  the  use  of  restart,  clear 
or  reset  procedures  aa  appropriate. 

A failure  on  levels  1 and/or  2 is  defined  aa  a condition  in  which  the  DCE  cannot 
transmit  and  receive  any  frames  because  of  abnormal  conditions  caused  by  for  instance 
line  fault  betiraen  DTE  and  DCE. 

When  a failure  on  levels  1 and/or  2 is  detected,  the  DCE  will  transmit  to  the 
remote  end 

(a)  a reset  indicating  Out  of  Order  for  a permanent  virtual  circuit  and 

(b)  a clear  indicating  Out  of  Order  for  an  existing  virtual  call. 

During  the  failure,  the  DCE  will  clear  any  incoming  virtual  calls  and  discard 
any  incoming  datagrama  and  datagram  service  signals. 

When  the  failure  ia  recovered  on  levels  1 and  2,  the  DCE  will  send  a RESTART  INDICATION 
packet  indicating  Network  Operational  to  the  local  DTE  and  this  will  result  in 
a reset  indicating  Remote  DTE  Operational  to  be  transmitted  to  the  remote  end 
of  each  permanent  virtual  circuit. 
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In  ocher  out  of  order  condition*  on  level  1 end/or  2,  including  tr«n*Bi**ion  of 
• DISC  cowand  by  the  DTE,  the  behavior  of  the  DCE  ia  for  further  aCudy. 

4.  F4CKKI  iOEMATS 

4.1  General  (Unchanged) 

4.1.1  General  Fonaat  Identifier 

The  General  Fonaat  Identifier  field  is  a four  bit  binary  coded  field  which  is 
provided  to  indicate  the  general  fonaat  of  the  reat  of  the  header.  The  General 
ForaaC  Identifier  field  is  located  in  bit  positions  8,  7,  6 and  S,  of  octet  1, 
and  bit  5 is  the  low  order  bit  (see  Table  5/X.2S). 

TWo  of  the  aixteen  possible  codes  are  used  to  identify  the  formats  for  the  DTE/DCE 
interface  defined  herein,  idiich  provide  for  virtual  call,  peraanent  virtual  circuit, 
and  datagram  facilities.  TVo  other  codes  are  used  to  identify  the  siailar  foraat* 
in  the  case  sequence  numbering  scheae  of  data  packet*  is  perforaed  aodulo  128. 

Other  codes  of  the  General  Foraat  Identifier  are  unassigned. 

NOTE:  It  is  envisaged  that  unassigned  codes  could  identify  alternative  packet 

foraats  associated  with  other  facilities  or  simplified  access  procedures, 
for  exanple,  single  access  DTE  procedures. 


TABU  5/X.2S 

GENERAL  FORMAT  IDENTIFIER 


GENERAL  FORMAT  IDENTIFIER 

Octet  1 
bits 

8 7 6 5 

Data,  datagram  and  datagram 
service  signal  packets 

Sequence  numbering  scheme 
aodulo  8 

X 0 0 1 

Sequence  nuabering  scheme 
modulo  128 

X 0 1 0 

Call  set-up  and  clearing, 
flow  control,  interrupt,  reset 
and  restart  packet* 

Sequence  nuabering  scheme 
aodulo  8 

0 0 0 1 

Sequence  numbering  scheme 
aodulo  128 

0 0 10 

NOTE:  A bit  idiich  is  indicated  aa  "X"  nay  be  set  to  either  "0"  or  "1"  as  discuased 
in  subsequent  sections. 

4.1.2  Logical  Channel  Croup  Ihasber  (Ucchanged) 

4.1.3  Logical  Channel  Number  (Unchanged) 

4.1.4  Facket  Type  Identifier 


Each  packet  ahall  be  identified  in  the  octet  3 of  the  packet  according  to  the  * f 

following  Table  6/X.2S.  J 


TABLE  6/X.25 


PACKET  TYPE  IDENTIFIBE 


1 PACKET  TYPE 

8 

7 

OCTET 
BITS 
6 5 4 

3 

3 

2 

1 

PROM  DCE  ID  DTE 

FROM  DTE  TO  ME 

CALL 

SET-UP 

AMD  CLEARING 

INCONIMG  CALL 

CALL  REQUEST 

0 

0 

0 

0 

1 

0 

1 

1 

CALL  CONNECTED 

CALL  ACCEPTED 

0 

0 

0 

0 

1 

1 

1 

1 

CLEAR  INDICATION 

CLEAR  REQUEST 

0 

0 

0 

1 

0 

0 

1 

1 

DCE  CLEAR  CONFIRMATION 

DTE  CLEAR  OONFIRMATION 

0 

0 

0 

1 

0 

1 

1 

1 

DATA  AND 

INTERRUPT 

DCE  DATA 

DTE  DATA 

X 

X 

X 

X 

X 

X 

X 0 

DCE  INTERRUPT 

DTE  INTERRUPT 

0 

0 

1 

0 

0 

0 

1 

1 

ME  INTERRUPT 

DTE  INTERRUPT 

CONFIRMATION 

OONFIRMATION 

0 

0 

1 

0 

0 

1 

1 

1 

ME  DATAGRAM 

DTE  DATAGRAM 

X 

X 

X 

X 

X 

X 

X 

0 

DATAGRAM  SERVICE  SIGNAL 

X 

X 

X 

X 

X 

X 

X 

0 

FLOW 

CONTROL  AND  RESET 

ME  RR 

DTE  RR 

X 

X 

X 

0 

0 

0 

0 

1 

ME  RNR 

DTE  RNR 

X 

X 

X 

0 

0 

1 

0 

1 

DTE  REJ* 

X 

X 

X 

0 

1 

0 

0 

1 

RESET  INDICATION 

RESET  REQUEST 

0 

0 

0 

1 

1 

0 

1 

1 

ME  RESET  CONFIRMATION 

DTE  RESET  CONFIRMATION 

0 

0 

0 

1 

1 

1 

1 

1 

MB  RR  (MODULO  128)* 

DTE  RR  (MODULO  128)* 

0 

0 

0 

0 

0 

0 

0 

1 

ME  RNR  (MODULO  128)* 

DTE  RNR  (MODULO  128)* 

0 

0 

0 

0 

0 

1 

0 

1 

DTE  REJ  (MODULO  128)* 

0 

0 

0 

0 

1 

0 

0 

1 

RESTART 

RESTART  INDICATION 

RESTART  REQUEST 

1 

1 

1 

1 

1 

0 

1 

1 

ME  RESTART  CONFIRMATION 

DTE  RESTART  CONFIRMATION 

1 

1 

1 

1 

1 

1 

1 

1 

Kot  neccitarily  available  on  every  network.  Use  of  the  DTE  REJ  packet  is  deacribed 
in  aection  5.1.5. 


MOTE:  A bit  Which  ii  indicated  as  "X"  aay  be  set  to  either  "0"  or  "1"  as  discussed 
in  subsequent  sections. 

4.2  Call  Set-up  and  Clearing  Packets  (Unchanged) 

4.3  Data.  Interrupt.  Datagran,  and  Datagrasi  Service  Signal  Packets 

4.3.1  PTE  and  DCE  Data  Packets  (Unchanged) 

4.3.2  DTE  and  DCE  Interrupt  Packets  (Unchanged) 

4.3.3  DTE  and  DCE  Interrupt  Confirmation  Packets  (Unchanged) 

4.3.4  Datagram  Packets 

Figure  5 bis/X.25  illustrates  the  format  of  DTE  and  DCE  datagram  packets. 


1 
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Qualifier  Bit 

Bit  8 in  Octet  1 ia  the  QUALIFIER  bit  and  is  always  set  to  0. 

Packet  Receive  Sequence  Humber 

Bita  8,  7 and  6 of  octet  3,  or  bits  8 through  2 of  octet  4 when  extended, 
ara  uaed  for  indicating  the  Packet  Receive  Sequence  Muaber  P(R).  P(R)  is  binary 
coded  and  bit  6,  or  bit  2 when  extended,  is  the  low  order  bit. 

Packet  Send  Sequence  Runber 

Bits  4,  3 and  2 of  octet  3,  or  bits  8 through  2 of  octet  3 when  extended, 
are  uaed  for  indicating  the  Packet  Send  Sequence  Number  P(S).  P(S)  is  binary 
coded  and  bit  2 is  the  low  order  bit. 

Address  Lengths  Field 

The  octet  following  the  sequence  numbers  consists  of  field  length  indicators 
for  the  destination  and  source  DTE  addresses.  Bits  4,  3,  2 and  1 indicate  the 
length  of  the  destination  DTE  address  in  semi-octets.  Bits  8,  7,  6 and  S indicate 
the  length  of  the  source  DTE  address  in  semi-octets.  Bach  address  length  indicator 
ia  binary  coded  and  bit  1 or  5 is  the  low  order  bit  of  the  indicator. 

Address  Field 


The  octets  following  the  Address  Length  Field  consist  of  the  destination 
DTE  address  when  present,  then  the  source  DTE  sddress  when  present. 

Each  digit  of  an  address  is  coded  in  a semi-octet  in  binary  coded  decimal 
with  bit  5 or  1 being  the  low-order  bit  of  the  digit. 

Starting  from  the  high  order  digit,  the  address  is  coded  in  consecutive 
octets  with  two  digits  per  octet.  In  each  octet,  the  higher  order  digit  is  coded 
in  bits  8,  7,  6 and  5. 

The  Address  Field  shall  be  rounded  up  to  an  integral  number  of  octets 
by  inserting  xeros  in  bits  4,  3,  2 and  1 of  the  last  octet  of  the  field  when  necessary. 

lOTE:  This  field  may  be  used  for  optional  addressing  facilities  such 

as  abbreviated  addressing.  The  optionsl  addressing  facilities  employed 

as  well  as  the  coding  of  those  facilities  is  for  further  study. 

Facility  Length  Field 

Bits  6,  5,  4,  3,  2 and  1 of  the  octet  following  the  Address  Field  indicate 
the  length  of  the  Facility  Field  in  octets.  The  facility  length  indicator  is 
binary  coded  and  bit  1 is  the  low  order  bit  of  the  indicator. 

Bits  8 and  7 of  this  octet  are  unassigned  and  set  to  0. 

Facility  Field 

The  Facility  Field  is  present  only  when  the  DTE  is  using  an  optional 
osar  facility  requiring  some  indicstion  in  the  datagram  packet. 

The  coding  of  this  Facility  Field  is  defined  in  Section  5. 

The  Facility  Field  contains  an  integral  number  of  octets.  The  actual 
■axim\a  length  of  this  field  depends  on  the  facilities  which  are  offered  by  the 
network.  Inraver  this  maximum  does  not  exceed  62  octets. 


Uier  Data  Field 


Folloving  the  facility  field,  the  user  data  field  cay  be  preaent  and 
baa  a Baxiaua  length  of  128  octeta.  The  firat  two  octeta  of  the  uaer  data  field 
are  called  the  datagrao  identifier. 

4.3.5  Datagraa  Service  Signal  Paekete 

Figure  5ter/X.2S  illuatratea  the  format  of  datagram  aervice  aignal  packeta. 

Qualifier  Bit 

Bit  8 of  octet  1 ia  the  QUALIFIER  bit  and  is  always  set  to  1. 

Pecket  Receive  Sequence  Humber 


Bits  8,  7 and  6 of  octet  3,  or  bits  8 through  2 of  octet  4 when  extended, 
are  used  for  indiceting  the  Packet  Receive  Sequence  Number  P(R).  P(R)  is  binary 
coded  and  bit  6,  or  bit  2 when  extended,  ia  the  low  order  bit. 

Packet  Send  Sequence  Number 

Bit  4,  3 and  2 of  octet  3,  or  bits  8 through  2 of  octet  3 when  extended, 
are  used  for  indicating  the  Packet  Send  Sequence  Number  P(S).  P(S)  is  binary 
coded  and  bit  2 ia  the  low  order  bit. 

Address  Lengths  Field 

The  octet  following  the  sequence  numbers  consists  of  field  length  indicators 
for  the  destination  and  source  DTE  addresses.  Bits  4,  3,  2 and  1 indicate  the 
length  of  the  destination  DTE  address  in  semi-octets.  Bits  8,  7,  6 and  5 indicate 
the  length  of  the  source  DTE  address  in  semi-octets.  Each  address  length  indicator 
is  binary  coded  and  bit  1 or  5 is  the  low  order  bit  of  the  indicator. 

Address  Field 


The  octets  following  the  Address  Length  Field  consist  of  the  destination 
DTE  address  when  present,  then  the  source  DTE  address  when  present  (see  Section 
3.3.7). 


Each  digit  of  an  address  is  coded  in  a semi-octet  in  binary  coded  decimal 
with  bit  S or  1 being  the  low-order  bit  of  the  digit. 

Starting  from  the  high  order  digit,  the  address  is  coded  in  consecutive 
octets  with  two  digits  per  octet.  In  each  octet,  the  higher  order  digit  is  coded 
in  bits  8,  7,  6 and  5. 

The  Address  Field  shall  be  rounded  up  to  an  integral  number  of  octets 
by  inserting  seros  in  bits  4,  3,  2 and  1 of  the  last  octet  of  the  field  when  necessary 

Datagram  Identification  Field 

The  datagram  identification  field  contains  the  first  two  octets  of  the 
user  data  field  from  the  original  datagram  to  tdiich  the  datagram  service  signal 
packet  applies.  If  the  user  data  field  of  the  original  datagram  it  lest  than 
two  octets,  the  datagram  identification  field  in  the  datagram  service  signal  packet 
will  be  padded  mit  to  two  octets  by  inserting  the  appropriate  number  of  0 bits. 

Cause  Field 


The  octet  immediately  following  the  datagram  identification  field  is 
the  cause  field  and  contains  the  reason  for  the  datagram  Service  Signal. 

The  coding  of  the  Cause  Field  is  given  in  Table  /X.25. 
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DiaKOoitic  Code 


Ihe  octet  iBcdiately  following  the  Cause  Field  contains  additional 
inforaation  on  the  reason  for  the  datagraa  service  signal. 


The  bits  of  the  Diagnostic  Code  in  a datagraa  service  signal  packet 
are  all  set  to  sero  When  no  specific  additional  inforaation  for  the  service  signal 
is  supplied.  Other  valuea  are  for  further  study. 


IDTE:  The  contents  of  the  diagnostic  code  field  do  not  alter  the  aeaning 
of  the  cause  field.  A DTE  is  not  required  to  undertake  any  action  on 
the  contents  of  the  diagnostic  code  field.  Unspecified  code  combinations 
in  the  diagnostic  code  field  shall  not  cause  the  DTE  to  not  accept  the 
cause  field. 


network  Inforaation  Field 


Following  the  Diagnostic  Field,  the  Network  Information  Field  may  be 
present  and  has  a maximum  length  of  16  octets. 


The  information  content  of  this  field  is  for  further  study. 

4.4  Flow  Control  and  Reset  Packets  (Unchanged) 

4.5  Restart  Packets  (Unchanged) 

4.6  Packets  Required  for  Optional  User  Facilities  (Unchanged) 

5.  PROCEDURES  AND  FORMATS  FDR  OPTIONAL  USER  FACILITIES  TO  BE  STUDIED 


The  following  is  a technical  description  of  procedures  and  formats  for  user  facilities 
which  have  been  proposed  for  study  for  inclusion  in  Reconnendation  X.2,  this  being 
for  further  study. 


NOTE;  However,  the  closed  user  group  facility  is  already  mentioned  in  Recosnendation 
X.2. 


5.1  Procedures  for  Optional  User  Facilities 

5.1.1  Reverse  Charging 


Reverae  Charging  is  an  optional  user  facility;  it  can  be  requested  by  a DTE  for 
a given  virtual  call  or  for  a datagram. 


The  reverse  charging  facility  needs  some  indication  in  the  CALL  REQUEST,  INCOMING 
CALL,  DTE  DATAGRAM  AND  DCE  DATAGRAM  packets. 


5.1.2  Throughput  Class  Selection  and  Indication  (Unchanged  except  add  Note  3). 


KITE  3:  Relating  to  datagram  operation,  the  following  has  been  identified  for 

further  study: 


a.  the  attainaent  of  throughput  on  a given  datagram  logical  channel. 
The  question  of  whether  window  sixe  selection  fulfills  this  requirement 

was  raised. 


b.  the  necessity  of  discriainating  between  throughput  on  datagraa  logical 
channels  compared  with  logical  channels  used  for  virtual  cal Is /permanent 
virtual  circuits. 


In  addition,  the  relationship  between  throughput  and  priority/ 
traffic  class  as  possible  further  fscilities  needs  to  be  studied. 
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Kavcrae  Charging  Acceptance  i*  an  optional  uaer  facility  agreed  for  a period  of 
tiae* 


This  user  facilityi  if  subscribed  to,  authorises  the  DC2  to  transmit  to  the  DTE 
incoming  calls  or  datagrams  which  request  the  Reverse  enlarging  facility*  In  the 
absence  of  this  facility«  the  DCE  will  not  transmit  to  the  DTE  incoming  calls 
or  datagrams  which  request  the  Reverse  charging  facility. 


5.1.4  One  Hay  Logical  Channel 


(unchanged) 


5.1.5  Packet  Retransmission 


Packet  Retransmission  is  an  optional  user  facility  agreed  for  a period  of  time. 

This  user  facility  allows  a DTE  to  request  retransmission  of  one  or  several  consecutive 
flow  controlled  packets  from  the  DCE  by  transferring  across  the  DTE/DCE  interface 
a DTE  REJECT  packet  specifying  a logical  channel  number  and  a sequence  number 
P(R).  The  value  of  this  P(r)  should  be  within  the  range  from  the  last  P(R)  received 
by  the  DCE  up  to,  but  not  including,  the  P(S)  of  the  next  flow  controlled  packet 
to  be  transmitted  by  the  DCE. 


When  receiving  a DTE  REJECT  packet,  the  DCE  initiates  on  the  specified  logical 
channel  retransmission  of  the  flow  controlled  packets;  the  Packet  Send  Sequence 
Numbers  of  which  are  starting  from  P(R)  where  P(R)  is  indicated  in  the  DTE  REJECT 
packet.  Until  the  DCE  transfers  across  the  DTE/DCE  interface  a flow  controlled 
packet  with  a Packet  Send  Sequence  Number  equal  to  the  P(R)  indicated  in  the  DTE 
REJECT  packet,  the  DCE  will  consider  the  receipt  of  another  DTE  REJECT  packet 
as  a procedure  error  and  reset  the  virtual  call,  permanent  virtual  circuit  or 
datagram  channel. 

Additional  flow  controlled  packets  pending  initial  transmission  may  follow  the 
retransmitted  packet (s). 

A DTE  receive  not  ready  situation  indicated  by  the  transmission  of  RMR  packet 
is  cleared  by  the  transmission  of  a DTE  REJECT  packet. 

The  conditions  under  which  the  DCE  ignores  a DTE  REJECT  packet,  or  considers  it 
as  a procedure  error,  are  those  described  for  flow  control  packets. 


5.1.6  Closed  User  Group  Facility 


Closed  User  Group  is  sn  optional  user  facility  agreed  for  a period  of  time  between 
the  Administration  and  a group  of  users. 


This  facility  permits  the  users  of  the  group  to  communicste  with  each  other,  but 
precludes  coomunication  with  all  other  users. 

A DTE  suiy  belong  to  more  than  the  closed  user  group. 

The  calling/source  DTE  should  specify  the  closed  user  group  selected  for  a virtual 
call  or  datagram  using  the  optional  user  fscility  parameters  in  the  CALL  REQUEST 
or  DTE  DATAGRAM  packet. 

The  closed  user  group  selected  for  a virtual  call  or  datagram  will  be  indicated 
to  a called/destination  DTE  using  the  optional  user  facility  parameters  in  the 
INOOMINC  CALL  or  DCE  DATAGRAM  packet. 


Wien  a DTE  only  belongs  to  one  closed  user  group,  this  indication  may  not  be  present 
in  the  CALL  REQUEST,  INCOMING  CALL,  DTE  DATAGRAM  or  DCE  DATAGRAM  packet. 


5.1.7  lil«ter«l  Closed  Pier  Croup  Facility 


k Bilmtcral  Closed  User  Croup  facility  is  an  optional  user  facility  which  can 
be  used  for  a period  of  tine  by  a DTE  for  a virtual  call  or  a datagram.  This 
facility  permits  such  users  to  communicate  with  each  otheri  but  precludes  coanunication 
with  all  other  users. 

k DIB  may  belong  to  more  than  one  bilateral  closed  user  group. 

The  ealling/source  DTE  should  specify  the  bilateral  user  group  selected  for  a 
virtual  call  or  datagram  using  the  optional  user  facility  paraiteters  in  the  CALL 
BBQOBST  or  DTE  DATAGRAM  packet.  The  called/destination  DTE  address  length  shall 
be  coded  all  seros. 

The  bilateral  closed  user  group  for  a virtual  call  or  datagram  will  be  indicated 
to  a called/destination  DTE  using  the  optional  user  facility  parameters  in  the 
INCOMING  CALL  or  DCE  DATAGRAM  packet. 

5.1.8  Abbreviated  Addressing 

Abbreviated  addressing  for  datagrams  is  an  optional  user  facility  agreed  for  a 
period  of  time.  This  facility  permits  encoding  of  sddresses  into  shorter  representations 
as  agreed  between  the  Administration  and  DTE.  Initially  this  facility  is  restricted 
to  a 1:1  oMpping  of  single  addresses,  but  1:N  mapping  for  multiple  addresses  is 
for  further  study. 

5.1.9  Datagram  Service  Signals 

The  following  datagram  service  signals  are  optional  user  facilities  which  may 
be  agreed  for  a period  of  time  or  selected  on  a per-datagram  basis: 

a.  Non-delivery  indication  is  provided  by  the  network  when  a datagram  cannot 
be  delivered  to  the  destination  DTE. 

b.  Delivery  confirmation  is  provided  by  the  network  after  the  datagram  has 
been  accepted  by  the  destination  DTE. 

5.1.10  Datagram  Service  Signal  Logical  Channel 

The  datagram  service  signal  logical  channel  is  an  optional  user  facility  agreed 
for  a period  of  time.  A separate  logical  channel  is  designated  for  a DTE  to  receive 
only  datagram  service  signals.  This  enables  the  DTE  to  separately  flow  control 
datagram  service  signal  packets  from  the  datagram  packets 

5.1.11  DCE  Queue  Length  Selection 

The  DCE  queue  length  per  datagram  logical  channel  is  an  optional  user  facility 
agreed  for  a period  of  time.  This  facility  enables  selection  of  the  number  of 
datagram  and  datagram  service  signal  packets  that  will  be  stored  in  a queue  by 
the  destination  DCE  when  the  rate  of  arrival  of  packets  at  the  destination  DCE 
from  other  sources  exceeds  the  rste  of  delivery  of  packets  to  the  destination 
DTE. 


5.1.12  Other  Datagram  Related  Facilities  Pnder  Consideration 

a.  Priority 

b.  Traffic  class 

c.  Broadcast 

d.  Datagram  redirection 

e.  Interrupt  datagram 

f.  Delayed  delivery 

g.  Suppression  of  service  signals 


5.2  Fof«ta  for  Option«l  Uter  F«cilitie» 
5.2.1  General 


1h«  facility  ficild  is  praaant  only  when  a DTS  ie  uaiog  an  optional  uaer  facility 
requiring  aoae  indication  in  the  CALL  KEQUESTi  INOOMING  CALLi  DTE  DATAGRAM  or 
DCS  DATAGRAM  packet. 

(laaaiains  paragrapha  of  thia  eeetion  unchanged  eacept  for  laat  3 paragraphs  of 
thia  eeetion). 

The  coding  of  the  paraneter  field  will  be  either  all  aeroa  or  all  onea  depending 
on  whether  the  facility  requeata  following  the  warker  refer  to  facilitiea  offered 
by  the  calling/aource  or  called/deatination  network,  reapectively.  For  intra- 
network virtual  calla  or  datagram,  the  parameter  field  ahould  be  all  teroa. 

Requeata  for  facilitiea  offered  by  the  calling/aource  and  called/deatination  networka 
may  be  ainultaneoualy  preaent  within  the  facility  field  and  in  auch  caaea  two 
Facility  Markera  will  be  required  with  parameter  fielda  coded  aa  deacribed  above. 

Within  the  facility  field,  requeata  for  X.25  facilitiea  will  precede  all  requeata 
for  nan-X.25  facilitiea  and  Facility  Markera  need  only  be  included  when  requeata 
for  nott-X.25  facilitiea  are  preaent. 

5.2.2  Codina  of  Facility  Field  for  Particular  Facilitiea 

5. 2. 2.1  Godina  of  Reverae  charaina  Facility 

The  coding  of  the  facility  code  and  parameter  fielda  for  Reverae  Charging  ia  the 
aame  in  tiar.r.  RRQVEST,  INCOMING  CALL,  DTE  DATAGRAM,  and  DCE  DATAGRAM  packeta. 

(Remainder  unchanged) 

5. 2. 2. 2 Codina  of  Throuahput  Claea  Selection  and  Indication  Facility  (Unchanged) 

5. 2. 2. 3 Codina  of  Cloaed  Uaer  Croup  Facility 

The  coding  of  facility  code  field  and  parametera  for  Cloaed  Uaer  Group  ia  the 
aame  in  rail.  REQUEST  INCOMING  CALL,  DTE  DATAGRAM  and  DCE  DATAGRAM  packeta. 

(Remainder  lachanged) 

5. 2. 2. A Codina  of  Bilateral  Cloaed  Uaer  Group  Facility 

The  ceding  of  facility  code  field  and  the  format  of  the  facility  parameter  field 
for  Rilateral  Cloaed  Uaer  Croup  are  the  aame  in  CALL  REQUEST,  INCOMING  CALL,  DTE 
DATAGRAM  and  DCS  DATAGRAM  packeta. 

(Remainder  umchanged) 

5. 2. 2. 5 Codina  of  Other  Dataaram  Related  Facilitiea 
For  fcrther  atudy  ia  the  encoding  oft 

a.  datagram  aarvice  aignal  requeata  - non-delivery  indication  and  delivery 
confirmation 

b.  other  facilitiea  aa  adopted  from  Section  5.1.12 


t 
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riguret  1/X.2S  through  5/X.25  unchanged 

Figures  Sbit/X-2S  end  Ster/X.2S  are  naw  figure*  a*  attached 

Figures  6/X>25  through  14/X.25  unchanged 

Figure  15/X.25  revise  Mote  1 a*  follows s 

at  end  of  note  add  "and  datagraas" 

Figures  16/X.25  and  17/X.2S  unchanged 

Table  10  Add  to  note  5 the  following: 

"In  the  ease  of  a datagram  logical  channel,  the  DCS  discard*  the  received 
packet  and  indicates  a reset  by  transaitting  an  indication  of  Local  Procedure 
Error." 

Table  11  - revise  as  follows: 

In  the  first  column,  last  two  rows  - "DATA,  DATAGRAM,  IMTERRUFT,  . . 
and  "DATA  and  DATAGRAM  PACKETS.  . . " 

2nd  paragraph  of  explanation  of  flow  control  error  - "...  state  d2  for  peraanent 
virtual  circuits  and  datagraa  logical  channels,  the  DCE  ..." 

Table  12  - revise  as  follows: 

In  the  first  coluam,  fourth  row  - "DATA,  DATAGRAM,  INTERRUPT,  ..." 

At  the  end  of  Note  2 add  - "and  datagraas." 


TABLE  /X.25 

CODING  OF  CAUSE  FIELD  IN 
DATAGRAM  SERVICE  SIGNAL  RACKET 


87654321 

Non*d«Xlvery  Indication 

Dalivary  Confirmation 

for  furthar  study 

MOTE  : Other  causes  ere  for  further  study. 
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Fiqure  5t*r/X.25  - tx:e  dataqtui  service  tlqnal  packet  format 


